Specifically programmed computer-implemented engine systems for real-time on-demand discovery of available time slots across programmed schedule objects and methods of use thereof

ABSTRACT

In some embodiments, the present invention provides for a computer-implemented method, including at least the following steps to be performed by a specifically programmed computer processor of a schedule management computer system: electronically causing to display a specialized schedule GUI; where the specialized schedule GUI is configured to allow each user to: define a programmed schedule object, including a plurality of availability time periods (TimeWindows); each having TimeWindow parameters, and identifying when a time period is available or unavailable for booking; where the TimeWindow parameters include: a start date, a start time, an end time, at least one day of a week, and a period type; electronically and in real-time, generating a bitmask of days in a week for each TimeWindow of the TimeWindows; electronically and in real-time, storing schedule objects associated with the users in a specifically dedicated database.

RELATED APPLICATIONS

This application claims the priority of U.S. provisional patentapplication No. 62/077,751; filed Nov. 10, 2014; entitled “SYSTEM ANDMETHOD FOR PERMITTING A USER TO QUERY A LARGE NUMBER OF STORED SCHEDULESFOR A LIMITED NUMBER OF POTENTIALLY AVAILABLE TIME SLOTS,” which isincorporated herein by reference in its entirety for all purposes.

FIELD OF INVENTION

In some embodiments, the present invention is related to specificallyprogrammed computer-implemented engine systems for real-time on-demanddiscovery of available time slots across programmed schedule objects andmethods of use thereof.

BACKGROUND OF THE INVENTION

Interaction with schedules covering large scale data sets is ubiquitous.Activities that require specific systems and processes to interact withsuch schedules include but are not limited to, appointments (e.g.,medical, dental, spa, professional, training, etc.), bookings (e.g.,time slots for space, sport (golf, tennis, squash)), reservations (e.g.,hotels), rentals(e.g., car, vacation, equipment), invitations (e.g.,business, parties), social gatherings, sports leagues, etc.

SUMMARY OF THE INVENTION

In some embodiments, the present invention provides for acomputer-implemented method, including at least the steps of:electronically causing, via a computer network, by at least onespecifically programmed computer processor of a schedule managementcomputer system executing software to perform the method, to display afirst specialized schedule graphical user interface (a first specializedschedule GUI) on a screen of each computing device associated with eachuser of a plurality of users; where the first specialized schedule GUIis configured to allow each user to: i) define at least one programmedschedule object, including a plurality of availability time periods (aplurality of TimeWindows), and ii) associate at least one programmedschedule object with at least one of: 1) at least one user, 2) at leastone resource, and 3) at least one service; where each TimeWindow is: i)defined by a plurality of TimeWindow parameters, and ii) configured toidentify whether a corresponding time period is available for booking orunavailable for booking; where the plurality of TimeWindow parametersinclude: i) at least one first TimeWindow parameter, identifying a startdate for the corresponding time period, ii) at least one secondTimeWindow parameter, identifying a start time for the correspondingtime period, iii) at least one third TimeWindow parameter, identifyingan end time for the corresponding time period, iv) at least one fourthTimeWindow parameter, identifying at least one day of a week associatedwith the corresponding time period, and v) at least one fifth TimeWindowparameter, identifying a period type of the corresponding time period;electronically and in real-time, generating, by the at least onespecifically programmed computer processor, based, at least in part, onthe at least one fourth TimeWindow parameter, a first bitmask of days ina week for the corresponding time period of each TimeWindow of theplurality of TimeWindows; electronically and in real-time, storing, bythe at least one specifically programmed computer processor, a pluralityof schedule objects associated with the plurality of users in at leastone specifically dedicated database; electronically causing, via thecomputer network, by the at least one specifically programmed computerprocessor, to display a second specialized schedule graphical userinterface (a second specialized schedule GUI) on a screen of a computingdevice associated with a particular user, where the second specializedschedule GUI is configured to allow each user to submit an electronicquery seeking to determine when a particular time period associated withat least one user is available for booking or unavailable for booking;electronically receiving, via the computer network, by the at least onespecifically programmed computer processor, the electronic query of theparticular user; electronically and in real-time, determining, by the atleast one specifically programmed computer processor, based on theelectronic query of the particular user, a set of TimeWindows selectedfrom the plurality of schedule objects related to at least one of 1) theat least one user, 2) the at least one resource, and 3) the at least oneservice; electronically and in real-time, determining, by the at leastone specifically programmed computer processor, based on the electronicquery of the particular user, a set of TimeWindows selected from theplurality of schedule objects related to at least one of 1) the at leastone user, 2) the at least one resource, and 3) the at least one service;electronically and in real-time, generating, by the at least onespecifically programmed computer processor, a union structure of the setof TimeWindows; electronically and in real-time, determining, by the atleast one specifically programmed computer processor, based on the firstbitmask associated with each TimeWindow of the set of TimeWindows, asecond bitmask corresponding to the at least one union; electronicallyand in real-time, determining, by the at least one specificallyprogrammed computer processor, an intersection structure between theunion and the electronic query of the particular user to identify atleast one matched day of the week between the at least one union and theparticular time period identified in the electronic query of theparticular user; electronically and in real-time, determining, by the atleast one specifically programmed computer processor, when the at leastone matched day of the week includes the particular time periodidentified in the electronic query of the particular user, based, atleast in part, on: 1) the at least one second TimeWindow parameter of aparticular TimeWindow associated with the at least one matched day ofthe week; 2) the at least one third TimeWindow parameter of theparticular TimeWindow associated with the at least one matched day ofthe week; 3) the at least one second TimeWindow parameter of theparticular time period identified in the electronic query of theparticular user; and 4) the at least one third TimeWindow parameter ofthe particular time period identified in the electronic query of theparticular user; and electronically and in real-time, performing, by theat least one specifically programmed computer processor, one of: i)booking the particular time period for the particular user when the atleast one matched day of the week includes the particular time periodidentified in the electronic query of the particular user; and ii)generating an indication identifying that the particular time period isunavailable for booking when the at least one matched day of the weekexcludes the particular time period identified in the electronic queryof the particular user.

In some embodiments, the exemplary method of the present inventionfurther includes at least: electronically and in real-time, storing, bythe at least one specifically programmed computer processor, the unionstructure and the intersection structure in the at least onespecifically dedicated database.

In some embodiments, the plurality of parameters further include atleast one sixth parameter, identifying an end date for the correspondingtime period. In some embodiments, the period type of the correspondingtime period is selected from the group consisting of: once, daily,weekly, monthly, quarterly, and yearly. In some embodiments, theplurality of parameters further include at least one seventh parameter,identifying a particular date or a particular day which is within thecorresponding time period having the period type of monthly or yearly.In some embodiments, the plurality of parameters further include atleast one eighth parameter, identifying a frequency of the correspondingtime period. In some embodiments, the plurality of parameters furtherinclude at least one ninth parameter, identifying an interval for thefrequency of the corresponding time period. In some embodiments, theunion structure is based on a logical OR operation with the set ofTimeWindows. In some embodiments, the intersection structure is based ona logical AND operation.

In some embodiments, the present invention provides for a specificallyprogrammed schedule management computer system, including at least: atleast one specialized computer machine, including: a non-transientmemory, electronically storing particular computer executable programcode; and at least one computer processor which, when executing theparticular program code, becomes a specifically programmed computerprocessor of the specifically programmed schedule management computersystem that is configured to concurrently perform at least the followingoperations: electronically causing, via a computer network, to display afirst specialized schedule graphical user interface (a first specializedschedule GUI) on a screen of each computing device associated with eachuser of a plurality of users; where the first specialized schedule GUIis configured to allow each user to: i) define at least one programmedschedule object, including a plurality of availability time periods (aplurality of TimeWindows), and ii) associate at least one programmedschedule object with at least one of: 1) at least one user, 2) at leastone resource, and 3) at least one service; where each TimeWindow is: i)defined by a plurality of TimeWindow parameters, and ii) configured toidentify whether a corresponding time period is available for booking orunavailable for booking; where the plurality of TimeWindow parametersinclude: i) at least one first TimeWindow parameter, identifying a startdate for the corresponding time period, ii) at least one secondTimeWindow parameter, identifying a start time for the correspondingtime period, iii) at least one third TimeWindow parameter, identifyingan end time for the corresponding time period, iv) at least one fourthTimeWindow parameter, identifying at least one day of a week associatedwith the corresponding time period, and v) at least one fifth TimeWindowparameter, identifying a period type of the corresponding time period;electronically and in real-time, generating, based, at least in part, onthe at least one fourth TimeWindow parameter, a first bitmask of days ina week for the corresponding time period of each TimeWindow of theplurality of TimeWindows; electronically and in real-time, storing aplurality of schedule objects associated with the plurality of users inat least one specifically dedicated database; electronically causing,via the computer network, to display a second specialized schedulegraphical user interface (a second specialized schedule GUI) on a screenof a computing device associated with a particular user, where thesecond specialized schedule GUI is configured to allow each user tosubmit an electronic query seeking to determine when a particular timeperiod associated with at least one user is available for booking orunavailable for booking; electronically receiving, via the computernetwork, the electronic query of the particular user; electronically andin real-time, determining, based on the electronic query of theparticular user, a set of TimeWindows selected from the plurality ofschedule objects related to at least one of 1) the at least one user, 2)the at least one resource, and 3) the at least one service;electronically and in real-time, determining, based on the electronicquery of the particular user, a set of TimeWindows selected from theplurality of schedule objects related to at least one of 1) the at leastone user, 2) the at least one resource, and 3) the at least one service;electronically and in real-time, generating a union structure of the setof TimeWindows; electronically and in real-time, determining, based onthe first bitmask associated with each TimeWindow of the set ofTimeWindows, a second bitmask corresponding to the at least one union;electronically and in real-time, determining an intersection structurebetween the union and the electronic query of the particular user toidentify at least one matched day of the week between the at least oneunion and the particular time period identified in the electronic queryof the particular user; electronically and in real-time, determiningwhen the at least one matched day of the week includes the particulartime period identified in the electronic query of the particular user,based, at least in part, on: 1) the at least one second TimeWindowparameter of a particular TimeWindow associated with the at least onematched day of the week; 2) the at least one third TimeWindow parameterof the particular TimeWindow associated with the at least one matchedday of the week; 3) the at least one second TimeWindow parameter of theparticular time period identified in the electronic query of theparticular user; and 4) the at least one third TimeWindow parameter ofthe particular time period identified in the electronic query of theparticular user; and electronically and in real-time, performing one of:i) booking the particular time period for the particular user when theat least one matched day of the week includes the particular time periodidentified in the electronic query of the particular user; and ii)generating an indication identifying that the particular time period isunavailable for booking when the at least one matched day of the weekexcludes the particular time period identified in the electronic queryof the particular user.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention can be further explained with reference to theattached drawings, wherein like structures are referred to by likenumerals throughout the several views. The drawings shown are notnecessarily to scale, with emphasis instead generally being placed uponillustrating the principles of the present invention. Therefore,specific structural and functional details disclosed herein are not tobe interpreted as limiting, but merely as a representative basis forteaching one skilled in the art to variously employ the presentinvention.

FIG. 1A is a representation of a software implementation related to aschedule S for a person P in accordance with some principles of someembodiments the present invention;

FIGS. 1B, 1C and 1D are flow charts showing programmed process flow inaccordance with some principles of some embodiments of the presentinvention;

FIGS. 1E, 1F, 1G, 1H, 1I and 1J are diagrams representative ofprogrammed Union and Intersection software objects that are relied uponin various locations within FIGS. 1B, 1C and 1D;

FIG. 2A is a representation of a software implementation related to aschedule S including an expanded number of bookings, and FIG. 2B is aflow chart showing programmed process flow in accordance with someprinciples of some embodiments of the present invention, for example,executing a sample query of the schedule S in FIG. 2A;

FIG. 3A is a representation of a software implementation related to aschedule S including an expanded number of bookings in accordance withsome principles of some embodiments of the present invention, and FIG.3B is a flow chart showing a programmed process flow representative fora specifically programmed sample query of the schedule S in FIG. 3A;

FIG. 4 is a schematic diagram of software implementation related toexample schedules and a sample of a specifically programmed usergraphical interface in accordance with some principles of someembodiments of the present invention

FIG. 5 is a block diagram of a exemplary specifically programmed enginecomputer system in accordance with some principles of some embodimentsof the present invention; and

FIG. 6 is a block diagram in accordance with some principles of someembodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Among those benefits and improvements that have been disclosed, otherobjects and advantages of this invention can become apparent from thefollowing description taken in conjunction with the accompanyingfigures. Detailed embodiments of the present invention are disclosedherein; however, it is to be understood that the disclosed embodimentsare merely illustrative of the invention that may be embodied in variousforms. In addition, each of the examples given in connection with thevarious embodiments of the present invention is intended to beillustrative, and not restrictive.

Throughout the specification, the following terms take the meaningsexplicitly associated herein, unless the context clearly dictatesotherwise. The phrases “in one embodiment” and “in some embodiments” asused herein do not necessarily refer to the same embodiment(s), thoughit may. Furthermore, the phrases “in another embodiment” and “in someother embodiments” as used herein do not necessarily refer to adifferent embodiment, although it may. Thus, as described below, variousembodiments of the invention may be readily combined, without departingfrom the scope or spirit of the invention.

In addition, as used herein, the term “or” is an inclusive “or”operator, and is equivalent to the term “and/or,” unless the contextclearly dictates otherwise. The term “based on” is not exclusive andallows for being based on additional factors not described, unless thecontext clearly dictates otherwise. In addition, throughout thespecification, the meaning of “a,” “an,” and “the” include pluralreferences. The meaning of “in” includes “in” and “on.”

It is understood that at least one aspect/functionality of variousembodiments described herein can be performed in real-time and/ordynamically. As used herein, the term “real-time” is directed to anevent/action that can occur instantaneously or almost instantaneously intime when another event/action has occurred. In some embodiments, theterms “instantaneous,” “instantaneously,” “instantly,” and “in realtime” refer to a condition where a time difference between a first timewhen a search request is transmitted and a second time when a responseto the request is received is no more than 1 second. In someembodiments, the time difference between the request and the response isbetween less than 1 second and several seconds (e.g., 5-10 seconds).

As used herein, the term “dynamic(ly)” means that events and/or actionscan be triggered and/or occur without any human intervention. In someembodiments, events and/or actions in accordance with the presentinvention can be in real-time and/or based on a predeterminedperiodicity of at least one of: nanosecond, several nanoseconds,millisecond, several milliseconds, second, several seconds, minute,several minutes, hourly, several hours, daily, several days, weekly,monthly, etc.

In some embodiments, the inventive electronic systems includeselectronic mobile devices (e.g., smartphones, etc.) of users andserver(s) in the distributed network environment, communicating over asuitable data communication network (e.g., the Internet, etc.) andutilizing at least one suitable data communication protocol (e.g.,IPX/SPX, X.25, AX.25, AppleTalk, TCP/IP (e.g., HTTP), etc.).

In some embodiments, an exemplary specifically programmedcomputer-implemented engine of the present invention operates utilizingsoftware constructs of TimeWindows of available (or unavailable—booked)time (e.g., coded objects) to represent a Schedule (e.g., an electroniccalendar). For example, each TimeWindow construct (e.g., programmedobject/routine) has a Period feature of a particular type. Then, eachPeriod has a DayGroup property which is a bitmask of days of the weekthat this Period falls on as explained further therein. In someembodiments, the Periods features can have additional properties thatdetermine if a user is interested in an Interval property to be defined(e.g., every other, every third, etc.) and/or a particular Occurrence tobe defined (first, second, third, second from last, etc.)

For example, a particular Schedule could consist of “every Tuesday andThursday every week, as well as every first Monday of the month”availability data. In some embodiments, the exemplary specificallyprogrammed computer-implemented engine of the present inventiontransforms this Schedule to represent it with two TimeWindowsobjects/data constructs:

TimeWindow #1 is a Weekly Period with a DayGroup bitmask of “0010100”(FIG. 1A) (e.g., the right-most digit is Sunday); and

TimeWindow #2 is a Monthly Period with a DayGroup bitmask of “0000010”(FIG. 1A) (e.g., the right-most digit is Sunday) along with anOccurrence property is set to “first”.

In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention is configured tohave Periods objects to be limited to a particular Day. Then, theexemplary specifically programmed computer-implemented engine of thepresent invention transforms the Schedule to represent it withTimeWindows objects/data constructs as:

TimeWindow #1 is a Weekly Period falling on a Tuesday only with aDayGroup bitmask of “0000100” (e.g., the right-most digit is alwaysSunday);

TimeWindow #2 is a Weekly Period falling on a Thursday only with aDayGroup bitmask of “0010000” (e.g., the right-most digit is alwaysSunday); and

TimeWindow #3 is a Monthly Period with a DayGroup bitmask of “0000010”(e.g., the right-most digit is always Sunday) along with an Occurrenceproperty of “first”.

So if the exemplary specifically programmed computer-implemented engineof the present invention executes a query for availability on Tuesday, aresult could be determined by employing intersection of Tuesday with theunion of all TimeWindows (TWs).

In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention executes a queryfor availability on Tuesday by avoiding the DayGroup bitmask processingby designating Periods object to only fall on a particular Day,resulting in TimeWindows objects/data constructs represented as:

TimeWindow #1 is a Weekly Period with a Day of Tuesday

TimeWindow #2 is a Weekly Period with a Day of Thursday

TimeWindow #3 is a Monthly Period with a Day of Monday and an Occurrenceof “first”.

In this case, if the exemplary specifically programmedcomputer-implemented engine of the present invention executes a queryfor availability on Tuesday, a result could be determined but would haveto rely on exact matching of Tuesday with the Period Day of each TW,rather than employing intersection of Tuesday with the union of all TWs.In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention is configured torely on exact matching of requested dates against each TW of a Schedule.

FIG. 1A is a representation of a software implementation (such asprogrammable datasets) related to an example schedule S for a person Pin accordance with some principles of some embodiments of the presentinvention. In this example, S includes two “time window” sets that eachrepresent attributes (e.g., day(s) of the week, start/end time and startdate, etc.) of available time, and two time window sets that eachrepresent attributes of unavailable (booked) time. In some embodiments,the attributes start date and start/end time can be represented as inconventional scheduling systems, e.g., date code and military time. Insome embodiments,the days of the week within each time window set arerepresented as a “daygroup” set. As shown in FIG. 1A, in someembodiments, the daygroup set is a seven-slot bit string representationof the days of the week that could have availability, with Sunday beingthe least significant bit. In the depicted example a black squareindicates that this position bit has a value of “1”, or “ON”, and awhite square indicates a value of “0” or “OFF”.

FIGS. 1B, 1C and 1D are flow charts showing sample schematicsrepresentative of programmed computer queries for specific day and timeslots based on the schedule S represented by time window sets 1, 2, 3and 4. In addition, FIGS. 1E, 1F, 1G, 1H, 1I and 1J are diagramsrepresentative of bitwise logical OR (union) and AND (intersection)programmed computer operations used in these sample queries.

An illustrative Example of Logical Conjunction (AND)

As used herein, logical conjunction (AND) is a computer-executedoperation on two logical values, typically the values of twopropositions, that produces a value of true if both of its operands aretrue. The truth table, Table 1, for p AND q (also written as p∧q, Kpq, p& q, or p·q) is as follows:

TABLE 1 Logical Conjunction p q p ∧ q T T T T F F F T F F F F

For example, if both p and q are true, then the conjunction p∧q is true.For all other assignments of logical values to p and to q theconjunction p∧q is false. It can also be said that if p, then p∧q is q,otherwise p∧q is p. For example, where p and q are data bits, the syntaxfor p∧q in the Ruby programming language is: p & q.

An illustrative Example of Logical disjunction (OR)

As used herein, logical disjunction (OR) is an operation on two logicalvalues, typically the values of two propositions, that produces a valueof true if at least one of its operands is true.

The truth table, Table 2, for p OR q (also written as p∨q, Apq, p∥q, orp+q) is as follows:

TABLE 2 Logical Disjunction p q p ∨ q T T T T F T F T T F F F

For example, if p, then p∨q is p, otherwise p∨q is q. For example, wherep and q are data bits, the syntax for p∨q in the Ruby programminglanguage is: p|q.

For example, in case of operations represented in FIG. 1E (“Intersectionof TimeWindow Daygroups”), in the “Bitwise Logical AND of Daygroups”operation, the inputs can be represented as bitmasks of “0000100” (whenSunday corresponds to the right-most bit) and “0111110”, respectively;and, then, the AND (intersection) operation produces the output which isrepresented by the bitmask of “0000100”. In another example, in case ofoperations represented in FIG. 1I (“Union of TimeWindow Daygroups”)∧∧∨—in the “Bitwise Logical OR of Daygroups” operation, the inputs canbe represented as bitmasks of “0101010” and “0010100”, respectively;and, then, the OR (union) operation produces the output which isrepresented by the bitmask of “0111110”.

In the query of FIG. 1B, a user is utilizing the exemplary specificallyprogrammed computer-implemented engine of the present invention toreal-time, on-demand inquire (12) about availability of P on a specificday and time slot. The exemplary specifically programmedcomputer-implemented engine of the present invention then finds alladvertised time windows (14). In some embodiments, the exemplaryspecifically programmed computer-implemented engine of the presentinvention executes a bitwise logical OR operation on all of the daygroupbit-string representations of advertised time, shown in FIG. 1I and inFIG. 1B (16), to compute a union ∪ of time windows, and in particulardaygroups. In some embodiments, this union construct and/or discoveredresults from this union execution, “EX1U,” can be reused in otherqueries such that the bitwise logical OR operation need not be performedfor subsequent user queries, but can be retrieved from the computermemory. For example, in some embodiments, after a predetermined periodof time passed since the execution of a particular construct (e.g.,Union object, Intersection object), the discovered results are no longerutilized for subsequent querying.

In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention then executes abitwise logical AND operation on the daygroup of the union previouslydetermined or retrieved from memory, and the daygroup of the query, tocompute an intersection ∩. For example, the exemplary specificallyprogrammed computer-implemented engine of the present invention executesquerying in accordance with bit-string representations of the uniondaygroup and of the query daygroup, shown in FIGS. 1E and 1B (18).

If the intersection returns an available day of week, the process flowcontinues to subsequent steps including but not limited to: comparisonof available hours in the day that the intersection occurs on with thequery hour, comparison with date value, and any other steps that couldbe necessary to complete the search aspect of the schedulingapplication. However, if no available day of week exists, i.e., theintersection at step (18) returns a null value, the process ends.Accordingly, as discussed above, the exemplary specifically programmedcomputer-implemented engine of the present invention does not need toperform the actual date comparisons and the time of day comparisons onunnecessary data sets.

In the example of FIG. 1B, the exemplary specifically programmedcomputer-implemented engine of the present invention determines, at anhour-comparison step, that the query hour is not within the availablehours on the day that the intersection occurs, so the process flow ends,e.g., with a “not available” message delivered to the user, or asuitable indicator stored in a queue in a process flow involving a setof queries.

In the query of FIG. 1C, a user is utilizing the exemplary specificallyprogrammed computer-implemented engine of the present invention toinquire (12) about availability of P on a specific day and time slot.The exemplary specifically programmed computer-implemented engine of thepresent invention then finds all advertised time windows (14). In theexample query of FIG. 1C, the time windows were previously subjected toa bitwise logical OR operation and union EX1U was computed and stored,thus step (16) of FIG. 1B and the process sequence of FIG. 1I need notbe repeated (unless the set of advertised time windows changes for thegiven P). In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention queries,periodically at a predetermined time interval and/or in real-time, toassess if the set of advertised time windows has changed. In a followingstep (18), the exemplary specifically programmed computer-implementedengine of the present invention then executes a bitwise logical ANDoperation of the daygroup union EX1U and the query daygroup to obtain anintersection ∩. In this example, the intersection returns a particularday, and the corresponding attributes concerning the hours of the daywithin that intersection day are shown. In the query of FIG. 1C, theexemplary specifically programmed computer-implemented engine of thepresent invention determines in the hour comparison step (20) that thequery hour is within the available hours on the day that the time windowintersection (18) occurs. In some embodiments, the exemplaryspecifically programmed computer-implemented engine of the presentinvention can ignore certain attributes including time of day and actualdate until they are required at later stages of the flow.

In examples in which schedule S (FIG. 1A) contains time windowsrepresentative of unavailable time, based on the query flow in FIG. 1C,the exemplary specifically programmed computer-implemented engine of thepresent invention continues to determine whether the queried time slotis unavailable. In the example, schedule S (FIG. 1A) contains timewindow sets #3 and #4 indicative of unavailable (booked) time. These areidentified (24) by the exemplary specifically programmedcomputer-implemented engine of the present invention in the process flowof FIG. 1C, and the exemplary specifically programmedcomputer-implemented engine of the present invention determines a union∪ of these unavailable time window (24 a), as detailed in FIG. 1J. Insome embodiment, the exemplary specifically programmedcomputer-implemented engine of the present invention executes a bitwiselogical OR operation on all of the daygroup bit-string representationsof unavailable time windows. In some embodiments, the exemplaryspecifically programmed computer-implemented engine of the presentinvention then can reuse the resulting union dataset in other queries(not shown).

In a following step (26), the exemplary specifically programmedcomputer-implemented engine of the present invention executes a bitwiselogical AND operation on the union previously determined (24) orretrieved from memory (not shown), and the daygroup of the query (seeFIG. 1G), to compute an intersection ∩.

If the intersection of unavailable days results in the nulldetermination, a query response can be returned to the user, stored,and/or passed to another step indicating that the requested query isavailable (based on the prior determination in step (20)). On the otherhand, if the set returns one or more intersections, the exemplaryspecifically programmed computer-implemented engine of the presentinvention continues, step (28), to determine whether the query hour onthe intersection day is available.

As shown in FIG. 1G, TW3 and TW4, being unavailable, are considered“negative” values. Therefore, when TW3 having a time range of[1500-1700] is unioned with the query range of [900-1700] the result is[900-1500]. The negative values of TW3 results in its time range beingsubtracted.

FIG. 1D shows a process flow similar to that of FIG. 1C with a differentquery so that the determination at step (28) returns an “unavailable”result.

FIGS. 2A, 2B, 3A and 3B show additional examples using the hereinsystems and processes. Of course, a person having ordinary skill in theart would appreciate that the herein systems and processes of thepresent invention as described herein are able to query a numerousnumber of stored schedules for a number of potentially available timeslots to identify available time slots which would otherwise not beavailable due to availability time slot mismatching.

FIG. 2A is another example of a data object representing a schedule Sfor a person P. In some embodiments, the exemplary specificallyprogrammed computer-implemented engine of the present invention canutilize the software object representing the schedule S. In thisexample, the software object S can include four “time window” dataobject sets where each set has programmed attributes (day(s) of theweek, start/end time and start date) of available time. For example, theattributes start date and start/end time can be represented as inconventional scheduling systems, e.g., date code and military time. Thedays of the week within each time window set are represented as a“daygroup” set. As shown in FIG. 2A, the daygroup set is a seven-slotbit string representation of the days of the week that could haveavailability, with Sunday being the least significant bit. In thedepicted example a black square indicates that this position bit has avalue of “1”, or “ON”, and a white square indicates a value of “0” or“OFF”.

In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention utilizes the binaryrepresentation of a daygroup to union all available TimeWindows first,resulting in only one necessary comparison between desired date andunion of all TimeWindows in order to answer a query.

FIG. 2B, is a flow charts showing a sample query being executed by theexemplary specifically programmed computer-implemented engine of thepresent invention for specific day and time slots based on the scheduleS represented by time window sets 1, 2, 3 and 4: Is P availableWednesday, 2/5/2014 at 1200? A process flow for such query isrepresented in FIG. 2B.

In the query of FIG. 2B, a user utilizes the exemplary specificallyprogrammed computer-implemented engine of the present invention toinquire about availability of P on a specific day and time slot. In someembodiments, the exemplary specifically programmed computer-implementedengine of the present invention then determines all advertised timewindows (TimeWindows (TWs)). In some embodiments, the exemplaryspecifically programmed computer-implemented engine of the presentinvention executes a bitwise logical OR operation on all of the daygroupbit-string representations of advertised time to compute a union ∪ oftime windows, and in particular daygroups. This union can be reused bythe exemplary specifically programmed computer-implemented engine of thepresent invention in other queries on the same schedule S of FIG. 2A,such that the bitwise logical OR operation need not be performed forsubsequent user queries, but can be retrieved from memory (e.g.,permanent and/or temporary computer storage).

In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention executes a bitwiselogical AND operation on the daygroup of the union previously determinedor retrieved from memory, and the daygroup of the query, to compute anintersection ∩. In some embodiments, the exemplary specificallyprogrammed computer-implemented engine of the present invention executesin accordance with bit-string representations of the union daygroup andof the query daygroup. If the intersection returns an available day ofweek, the exemplary specifically programmed computer-implemented engineof the present invention continues to execute subsequent steps includingbut not limited to: comparison of available hours in the day that theintersection occurs on with the query hour, comparison with date value,and any other steps that could be necessary to complete the searchaspect of the scheduling application. However, if no available day ofweek exists, as in the example query in FIG. 2B, the intersection atstep returns an empty set or a null value, the exemplary specificallyprogrammed computer-implemented engine of the present invention thenstops the execution and can return an indication of such outcome (e.g.,a “not available” alert/message delivered to the user), and/orassign/associated/store a suitable indicator e, for example, in a queuein a process flow involving a set of queries.

FIG. 3A is a representation of another example of a software executionperformed by the exemplary specifically programmed computer-implementedengine of the present invention regarding a schedule S for a person P.In this example, S includes one “time window” set that representsattributes (day(s) of the week, start/end time and start date) ofavailable time, and four time window sets that each represent attributesof unavailable (booked) time. The attributes start date and start/endtime can be represented as in conventional scheduling systems, e.g.,date code and military time. The days of the week within each timewindow set are represented as a “daygroup” set. As shown in FIG. 3A, thedaygroup set is a seven-slot bit string representation of the days ofthe week that could have availability, with Sunday being the leastsignificant bit. In the depicted example a black square indicates thatthis position bit has a value of “1”, or “ON”, and a white squareindicates a value of “0” or “OFF”.

In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention utilizes the binaryrepresentation of a daygroup to union all unavailable TimeWindows andsubtract that union from the set of available days in order to determineif a desired date is still available.

In examples in which schedule S (FIG. 3A) contains time windowsrepresentative of unavailable time, the query flow in FIG. 3B proceedssimilar to that of FIG. 2B. As shown in FIG. 3B, the intersection ∩ ofthe desired query data with the TimeWindow#1 returns a non-empty set,i.e., an availability. In some embodiments, the exemplary specificallyprogrammed computer-implemented engine of the present invention thendetermines whether the query time of day is within the TimeWindow #1attributes. In the example of FIG. 3B, the query time of day isavailable based on the TimeWindow #1 attributes.

In some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention continues (theupper left portion of the flow diagram in FIG. 3B) to determine whetherthe queried time slot is unavailable. In the example, schedule S (FIG.3A) contains time window sets #2, #3, #4 and #5 indicative ofunavailable (booked) time. These are identified in the process flow ofFIG. 3B, and a union ∪ of these unavailable time window is obtained. Insome embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention executes a bitwiselogical OR operation on all of the daygroup bit-string representationsof unavailable time windows. In some embodiments, the exemplaryspecifically programmed computer-implemented engine of the presentinvention can reuse the resulting union in other queries (not shown)that search the same schedule S (i.e., until new bookings arise thusrequiring additional TimeWindows representative of unavailable time).Then, in some embodiments, the exemplary specifically programmedcomputer-implemented engine of the present invention can execute abitwise logical AND operation on the union previously determined orretrieved from memory (not shown), and the daygroup of the query, tocompute an intersection ∩. If the intersection of unavailable daysresults in the null determination, a query response can be returned tothe user, stored, and/or passed to another step indicating that therequested query is available). On the other hand (not shown in FIG. 3B),if the set returns one or more intersections, the exemplary specificallyprogrammed computer-implemented engine of the present invention isconfigured to continue to determine whether the query hour on theintersection day is available.

FIG. 4 is a schematic diagram of example schedules and a samplespecifically programmed updateable user graphical interface caused to begenerated by the exemplary specifically programmed computer-implementedengine of the present invention. In the data representation portion ofFIG. 4, example schedules are set forth including “Availability 1,”“Availability 2,” “Unavailability 1,” and “Unavailability 2.” In theavailability portions, the daygroup is represented by the days of theweek that could have availability, with a black square indicating thisposition it has a value of 1, or “ON,” and a white square indicates avalue of 0, or “OFF.” In the unavailability portions, this exampleschedule is modified as compared to the previous depictions. In thisrepresentation, unavailability is represented by, for example but notlimited to, black lines within the square corresponding to particularappointment times. In the exemplary specifically programmed updateableavailability user graphical interface for the user, the exemplaryspecifically programmed computer-implemented engine of the presentinvention utilizes we can see in this example that there is noavailability on Wednesday (a white block), there is availability for theentire Thursday, and there were periods of availability and periods ofunavailability on Friday. The representative block for Friday is theavailability for Friday minus the unavailability for Friday. In someembodiments, the exemplary specifically programmed computer-implementedengine of the present invention is configured to allow the user to booka particular available time slot.

An exemplary block diagram of a computer system 80 by which thescheduling modules of the present invention can be implemented is shownin FIG. 5. Computer system 80 includes a processor 82, such as a centralprocessing unit, an input/output interface 90 and support circuitry 92.In certain embodiments, where the computer 80 requires a direct humaninterface, a display 96 and an input device 98such as a keyboard, mouseor pointer are also provided. The display 96, input device 98, processor82, and support circuitry 92 are shown connected to a bus 94 which alsoconnects to a memory 88. Memory 88 includes program storage memory 111and data storage memory 191. Note that while computer 80 is depictedwith direct human interface components display 96 and input device 98,programming of modules and exportation of data can alternatively beaccomplished over the interface 90, for instance, where the computer 80is connected to a network and the programming and display operationsoccur on another associated computer, or via a detachable input deviceas is known with respect to interfacing programmable logic controllers.

Program storage memory 111 and data storage memory 191can each comprisevolatile (RAM) and non-volatile (ROM) memory units and can also comprisehard disk and backup storage capacity, and both program storage memory111 and data storage memory 191 can be embodied in a single memorydevice or separated in plural memory devices. Program storage memory 111stores software program modules and associated data, and in particularstores one or more modules 110. Data storage memory 191 stores the datasets representative of the schedules S including advertised time,bookings (unavailable time) and any union data generated by the one ormore modules of the present invention to be reused.

It is to be appreciated that the computer system 80 can be any computersuch as a personal computer, minicomputer, workstation, mainframe, adedicated controller such as a programmable logic controller, or acombination thereof. While the computer system 80 is shown, forillustration purposes, as a single computer unit, the system cancomprise a group/farm of computers which can be scaled depending on theprocessing load and database size. In certain embodiments, the systemand method herein can be operate on a user's computer, for instance, ina user's browser, querying among schedule data that resides on theuser's machine, after having been downloaded without query from anetworked server computer. However, not all of these components may berequired to practice the invention, and variations in the arrangementand type of the components may be made without departing from the spiritor scope of the invention. In some embodiments, the inventive system andmethod may include a large number of users and/or concurrenttransactions. In other embodiments, the instant inventive systems arebased on a scalable computer and network architecture that incorporatesvarious strategies for assessing the data, caching, searching, anddatabase connection pooling. An example of the scalable architecture isan architecture that is capable of operating multiple servers that arein real-time communicating with numerous electronic devices of users(e.g., smartphones). In some embodiment, the inventive systems ofpresent invention can host a large number of electronic devices of users(e.g., at least 100; at least 1,000, at least 10,000; at least 100,000;at least 1,000,000; at least 1,000,000,000, etc.) and/or perform a largenumber of concurrent actions/transactions (e.g., at least 1,000; atleast 10,000; at least 100,000; at least 1,000,000, at least1,000,000,000, etc.) with a numerous data Schedule S and TimeWindowssets (e.g., at least 1,000; at least 10,000; at least 100,000; at least1,000,000, at least 1,000,000,000, etc.).

The computing device 80 preferably supports an operating system, forexample stored in program storage memory 111 and executed by theprocessor 82 from volatile memory. According to an embodiment of theinvention, the operating system contains instructions for interfacingthe device 80 to the scheduling modules.

In various alternate embodiments, the present invention may beimplemented as a computer program product for use with a computerizedcomputing system. Those skilled in the art will readily appreciate thatprograms defining the functions defined by the present invention can bewritten in any appropriate programming language and delivered to acomputer in many forms, including but not limited to: (a) informationpermanently stored on non-writeable storage media (e.g., read-onlymemory devices such as ROMs or CD-ROM disks); (b) information alterablystored on writeable storage media (e.g., floppy disks and hard drives);and/or (c) information conveyed to a computer through communicationmedia, such as a local area network, a telephone network, or a publicnetwork such as the Internet. When carrying computer readableinstructions that implement the present invention methods, such computerreadable media represent alternate embodiments of the present invention.

For purposes of the instant description, the terms “cloud,” “Internetcloud,” “cloud computing,” “cloud architecture,” and similar termscorrespond to at least one of the following: (1) a large number ofcomputers connected through a real-time communication network (e.g.,Internet); (2) providing the ability to run a program or application onmany connected computers (e.g., physical machines, virtual machines(VMs)) at the same time; (3) network-based services, which appear to beprovided by real server hardware, and are in fact served up by virtualhardware (e.g., virtual servers), simulated by software running on oneor more real machines (e.g., allowing to be moved around and scaled up(or down) on the fly without affecting the end user). In someembodiments, the present invention offers/manages the cloudcomputing/architecture as, but not limiting to: infrastructure a service(IaaS), platform as a service (PaaS), and software as a service (SaaS).

Illustrative exemplary programming code utilized in programming theexemplary specifically programmed computer-implemented engine of thepresent invention to book an available time slot is provided below.

   ## The Book method    ###     # Attempts to book a specific timeslot. ‘object’ is the Service being booked.     def book!(params={ })     # finds all available schedules for search params...      schedules= object.available_schedules_near(params)      # there's a problem ifrequested duration is less than Service duration...     params[:duration] ||= object.duration     raise  Exceptions::InvalidParams.new(“422  Requested  :duration#{params[:duration]} is less than Service duration #{object.duration}”)unless params[:duration] >= object.duration      booking = nil      #iterate through available schedules...      schedules.each do |schedule|      gb_transaction do        schedule.lock! # with lock....        #check if schedule is still available...        ifschedule.has_availability_at?(params)        date = params[:date]       tw = TimeWindow.factory!({             ‘negation’ => true,            ‘recurs_by’ => ‘once’,             ‘frequency’ => ‘single’,            ‘start_date’ => date,             ‘days’ =>date.strftime(‘%A’).downcase,             ‘start_time’ =>mil_to_mins(date.strftime(‘%H%M’).to_i),            ‘end_time’  =>  mil_to_mins((date  +duration.minutes).strftime(‘%H%M’).to_i),             ‘total_minutes’ =>duration            }.merge(params))       schedule.time_windows << tw      # creates the booking...       booking = Booking.create!(user_id:params[:booker_id], time_window_id:       tw.id)       # clear any cacheof availabilities...       schedule.clear_availability_cache(tw)     end     end     break if booking # we only need to book for firstavailable Schedule found...    end    booking     end    end    ###   ## book! calls Service.available_schedules_near to findavailabilities    ###    ###    ## Service.available_schedules_neardefers to Schedule.has_availability_near?    ###    ###    ##Schedule.has_availability_near? defers to Schedule.availabilities    ###   ###    ## Schedule.availabilities defers toSchedule.time_window_availabilities    ###     deftime_window_availabilities(options={ })      available = SortedSet.new     if options[:date]       # select relevant TimeWindows if specificdate in daygroup, then collect possible day availabilities.      available_time_windows.select{|tw|tw.in_daygroup?(options[:date])}.each{|tw| available +=tw.events(options)}      elsif options[:start_dt] and options[:end_dt]      # if dealing with a range, test each day in range       date =options[:start_dt]       while date < options[:end_dt]       available_time_windows.select{|tw|  tw.in_daygroup?(date)}.each{|tw|available += tw.events(options)}        date += 1.day       end     else       # no specific date to match daygroups against...      available_time_windows.each{|tw| available += tw.events(options)}     end      available     end    ###    ## TimeWindow.in_daygroup?.date.wday is the weekday of date.    ###     def in_daygroup?(date)     daygroup & (2**date.wday) > 0 ## <== the & is Ruby syntax for abitwise intersection     end    ###    ## TimeWindow.daygroup    ##daygroup - set of active (boolean) day of week fields expressed as abitwise sum of 2{circumflex over ( )}(day of week) with :sunday => 0 asper Ruby/Rails convention    ## e.g. daygroup(:sunday=>true) impliesinteger value == 1    ## daygroup(:monday=>true) implies integer value== 2    ## daygroup(:saturday=>true) implies integer value == 64   ##    daygroup(:sunday=>true, :monday=>true, :tuesday=>true,:wednesday=>true, :thursday=>true, :friday=>true, :saturday=>true)implies integer value == 127    ###     # return the integer bitwiseaddition of the days of week as powers of 2 (see comment in header)    def daygroup      dg_bit = 0      # we rotate once from the end tostart with sunday, instead of monday as Time::DAYS_INTO_WEEK does     Time::DAYS_INTO_WEEK.keys.rotate(−1).each_with_index{ |day, index|dg_bit |= 1 << index if self.send(“#{day}?”.to_sym)}      dg_bit     End

Illustrative example of Application Program Interface code (API) havingexemplary rules utilized in programming and operation of the exemplaryspecifically programmed computer-implemented engine of the presentinvention to book available time slots In some embodiments, the API isconfigured/programmed to allow to manage Users and their Resources, suchas:

the Services/Activities the Users and/or their Resources offer

the Schedules of Services/Activities

the Booking of a Service at a particular time

Users can Search for any available scheduled Services/Activities

Basic Users

In some embodiments, a Basic User cannot create any Resources, the onlyResource they have is themselves. In some embodiments, a Basic User cancreate Services/Activities but they must be offered at no charge. Insome embodiments, Basic User accounts are free for the first year, and$1 per year after the first year.

Pro Users

In some embodiments, any Basic account can be upgraded to a Pro account.In some embodiments, Pro Users are able to create additional Resourcesunder their account. These Resources can have their own Schedules aswell as Services/Activities offered. Pro Users are also able to offerServices/Activities at a price to the customer. The price of aService/Activity can be fixed for the duration of the appointment,hourly, or various other options.

Access to the API

In some embodiments, Pro Users automatically gain access to the API. TheAPI allows for the creation and management of the Pro User's Resources,Services/Activities, Schedules and Bookings.

Account Manager

The API allows creation of other accounts for which the Pro User becomesthe defacto Account Manager. The Pro User, via API, can then create andmanage Resources, Services/Activities, and Schedules of Users for whichthey are the Account Manager. Account Managers have only limited accessto manage the Bookings of their managed Users. In some embodiments, anyUsers created via API are completely viewable and have their Servicesand Schedules.

Entities (Programmed Objects) (FIG. 6)

There are several Entities in the system accessible via API:

Users

Services/Activities

PricingModels

Schedules

Resources

Categories

Search Results

Bookings

Getting started using the API to make a User with Services that areadvertised can be done, for example, in as few as 5 steps. Use thiswalk-through to get up and running:

Step 1—Obtain Your Key

Step 2—Create a User

Step 3—Create a Service

Step 3.1—(Optional) Create a Category and associate with Service

Step 3.2—(Optional) Associate a Price Model with Service

Step 4—Create a Schedule for the new Service

Step 5—Check your work!

Step 1—Obtain an API Key

In some embodiments, to obtain an API Key, you must be registered as aGoneBusy User. You must upgrade from a Basic to a Pro account. Onceupgraded you can request an API Key from the Pro settings page. Afteragreeing to the Terms & Conditions of API access and usage, you will beissued an API Key. Keep this Key private. If you lose the Key, or feelit has been compromised, you can request another Key, which will makeany previous keys invalid. The API Key value is passed as a parameter toall API requests, using the parameter name ‘api_key’.

Step 2—Create a User

Once registered, your own User account has been created for you. As aPro User, you can now make changes via API to your own User account aswell as create/update other User accounts. For any User accounts thatyou create via API, you are the Account Manager for those User accounts.Likewise, any User account created via API could also (after upgradingto a Pro account) obtain their own API Key and manage their own accountas well as any additional User accounts that they create via the API.

Request:

Here is a sample POST request to create a new User:

with POST body:

-   -   “email”: “tutor@youremail.com”,    -   “first_name”: “Private”,    -   “last_name”: “Tutor”,    -   “business_name”: “Tutors-R-Us”,    -   “external_url ”: “tutors-r-us.sample.biz”,    -   “timezone”: “EST”,    -   “api_key”: “ac98ed08b5b0a9e7c43a233aeba84 1 ce”

Response:

Here is the response to the request, note the ID of our new User:

“Status”: “201 Created” { ″user″: { ″id″: 54, ″email″:″tutor@youremail.com″, ″first_name″: “Private”, ″last_name″: “Tutor”,″disabled″: false, ″business_name″: ″Tutors-R-Us″, ″external_url″:″tutors-r-us.sample.biz″, ″permalink″: null, ″timezone″: “EST”,″created_at″: ″2014-10-04T19:46:26Z″, ″updated_at″:″2014-10-04T19:46:26Z″, ″resource_id″: 267, ″account_manager_id″: 22,″address″: null } }

Step 3—Create a Service/Activity

A sample POST request to create a Service for our sample User:

Request:

with POST body:

-   -   “user_id”: 54,    -   “name”: “LSAT/MCAT Tutoring”,    -   “description”: “Tutoring for LSAT or MCAT exams. Available by        the hour.”,    -   “duration”: 60,    -   “api_key”: “ac98ed08b5b0a9e7c43a233aeba841 ce”

Response:

“Status”: “201 Created” { ″service″: { ″id″: 4183, ″owner_id″: 54,″resources″: [267], ″name″: ″LSAT/MCAT Tutoring″, ″short_name″: null,″duration″: 60, ″description″: ″Tutoring for LSAT or MCAT exams.Available by the hour.″, ″price_model_id″: null, ″is_active″: true,″categories″: “[ ]” } }

Step 3.1—Create a Category and Associate with a Service/Activity

The Service/Activity created in Step 3 above was not Associated with anyCategories during creation. We could have searched for Categories thatalready exist in the system and then specified the IDs of Categories atthe time of Service/Activity creation. We can also make our own Categoryas follows.

Here is a sample POST request to create a Category:

Request:

with POST body:

-   -   “name”: “Graduate School Exam Preparation”,    -   “description”: “Services related to preparing for graduate-level        entrance exams such as LSAT, MCAT, etc.”,    -   “api_key”: “ac98ed08b5b0a9e7c43a233aeba841ce”

Response:

“Status”: “201 Created” { ″category″: { ″id″: 23, ″name″: ″GraduateSchool Exam Preparation″, ″short_name″: null, ″long_name″: null,″description″: ″Service related to preparing for graduate-level entranceexams such as LSAT, MCAT, etc.″, ″parent_category_id″: null,″is_active″: true, ″subcategories″: [ ] } }

In some embodiments, we can now assign our recently created Service tothis Category. You can assign multiple Categories at once with acomma-delimited list of Category IDs, or just provide a single CategoryID.

Request:

with PUT body:

-   -   “categories”: “[23]”,    -   “api_key”: “ac98ed08b5b0a9e7c43a233aeba841ce”

Response:

“Status”: “200 OK” { ″service″: { ″id″: 4183, ″owner_id″: 54,″resources″: [ 267 ], ″name″: ″LSAT/MCAT Tutoring″, ″short_name″: null,″duration″: 60, ″description″: ″Tutoring for LSAT or MCAT exams.Available by the hour.″, ″price_model_id″: null, ″is_active″: true,″categories″: [ { ″id″: 23, ″name″: ″Graduate School Exam Preparation″,″short_name″: null, ″long_name″: null, ″description″: ″Service relatedto preparing for graduate-level entrance exams such as LSAT, MCAT,etc.″, ″parent_category_id″: null, ″is_active″: null, ″subcategories″: [] } ] } }

Step 3.2—(Optional) Associate a PricingModel with a Service

The Service created in Step 3 above was not Associated with aPricingModel during creation. Recall that a Service defaults to having“Activity” pricing if no PricingModel is specified, which means it mustbe offered at no charge. If we want to charge for our new Service, let'screate an appropriate PricingModel and associate it with our Service.

Here is a sample POST request to create a PricingModel:

Request:

with POST body:

-   -   “type”: “ByTheHour”,    -   “price”: 50.0,    -   “name”: “Tutoring Hourly Rate”,    -   “notes”: “Applies to LSAT, MCAT, SAT as well”,    -   “api_key”: “ac98ed08b5b0a9e7c43a233aeba841ce”

Response:

“Status”: “201 Created” { ″pricing_model″: { ″id″: 126, ″name″:″Tutoring Hourly Rate″, ″price″: 50.00, ″currency″: “USD”, ″notes″:″Applies to LSAT, MCAT, SAT as well″, “pricing_model_type”: “ByTheHour”} }

We can now assign our recently created Service to this PricingModelusing the ID of the PricingModel we just created:

Request:

with PUT body:

-   -   “price_model_id”: 126,    -   “api_key”: “ac98ed08b5b0a9e7c43a233aeba841 ce”

Response:

“Status”: “200 OK” { ″service″: { ″id″: 4183, ″owner_id″: 54,″resources″: [ 267 ], ″name″: ″LSAT/MCAT Tutoring″, ″short_name″: null,″duration″: 60, ″description″: ″Tutoring for LSAT or MCAT exams.Available by the hour.″, ″price_model_id″: 126, ″is_active″: true,″categories″: [ { ″id″: 23, ″name″: ″Graduate School Exam Preparation″,″short_name″: null, ″long_name″: null, ″description″: ″Service relatedto preparing for graduate-level entrance exams such as LSAT, MCAT,etc.″, ″parent_category_id″: null, ″is_active″: null, ″subcategories″: [] } ] } }

Step 4—Create a Schedule for the New Service

Now that a new User and Service have been created, we need to create aSchedule that specifies when the Service will be offered by the newUser. In some embodiments, without an explicit resource_id passed, thedefault resource of our new User will be assigned the new Schedule.Let's create the following Schedule for our “LSAT/MCAT Tutoring”Service: “Starting November 1st until January 31st, available everyMonday, Wednesday, Friday from 4 pm to 11 pm.” A Schedule is made up ofmany TimeWindows but for convenience it is encouraged to create aSchedule by passing parameters that will also create the firstTimeWindow in addition to the new Schedule. The following POST to createa Schedule will also create a TimeWindow that corresponds to the aboveavailability:

Request:

with POST body:

-   -   “service_id”: 4183,    -   “user_id”: 54,    -   “start_date”: “2014-11-01”,    -   “end_date”: “2015-01-31”,    -   “start_time”: “4 pm”,    -   “end_time”: “11 pm”,    -   “recurs_by”: “weekly”,    -   “days”: [“monday”, “wednesday”, “friday”],    -   “api_key”: “ac98ed08b5b0a9e7c43a233aeba84 1 ce”

Response:

“Status”: “201 Created” { ″schedule″: { ″id″: 8090, ″service_id″: 4183,″resource_id″: 267, ″time_windows″: [ { ″id″: 10536, ″start_date″:″2014-11-01”, ″end_date″: ″2015-01-31”, ″start_time″: ″4pm”, ″end_time″:″11pm”, ″total_minutes″: 420, ″recurs_by″: ″weekly”, ″days″: [″monday”,″wednesday”, ″friday”], ″frequency″: ″every”, ″occurrence″: ″every”,″date_recurs_by″: null, ″negation″: false } ] } }

Step 5—Check Your work

Now that our Schedule has been created for our “LSAT/MCAT Tutoring”Service, lets check what our available bookable time slots are onNovember 3rd:

Request:

GET

http://beta.gonebusy.com/api/v1/services/4183/available_slots.json?date=11-03-2014

Response:

“Status”: “200 OK” { ″service″: { ″id″: 4183, ″owner_id″: 54,″resources″: [ { “id″: 267, ″available_slots″: [ { ″date″: ″2014-11-03″,″slots″: [ ″04:00:00 PM″, ″04:15:00 PM″, ″04:30:00 PM″, ″04:45:00 PM″,″05:00:00 PM″, ″05:15:00 PM″, ″05:30:00 PM″, ″05:45:00 PM″, ″06:00:00PM″, ″06:15:00 PM″, ″06:30:00 PM″, ″06:45:00 PM″, ″07:00:00 PM″,″07:15:00 PM″, ″07:30:00 PM″, ″07:45:00 PM″, ″08:00:00 PM″, ″08:15:00PM″, ″08:30:00 PM″, ″08:45:00 PM″, ″09:00:00 PM″, ″09:15:00 PM″,″09:30:00 PM″, ″09:45:00 PM″, ″10:00:00 PM″ ] } ] } ] } }

Exemplary Entities

Users

Users are the people that participate on GoneBusy. If you haven't doneso already, take a look at our explanation of how Users interact withGoneBusy on the “How GoneBusy Works” page. In some embodiments, the APIallows a Pro User to manage themselves or an Account Manager to operateon managed users in order to offer services, schedule availability, andvarious other operations.

Services/Activities

In some embodiments, Bookings would not be possible without usersoffering their Services/Activities. Services can be anything thatsomeone, or a group of professionals at a business, offers for a feethat requires a time commitment. Activities also require a timecommitment but don't require charging a fee—for instance, Activities arethings one shares with friends.

PricingModels

Each Service a User offers must have a PricingModel associated with itin order to specify how to charge for the Service. There are severaltypes of PricingModels, including “Activity” which means the Service isactually an Activity that has no charge Associated with it. When aService is created without specifying a PricingModel, by default it willhave an Activity PricingModel Associated with it. To create a newPricingModel, one must specify the type of PricingModel (see below)along with any additional attributes the specific PricingModel requires.

There are several types of PricingModels that can be assigned to aService. If you have a need to price a Service/Activity in a manner thatis not accommodated by any of the PricingModels below, please let usknow and we'll be happy to assist you with creating a new PricingModelif necessary. In some embodiments, PricingModels can be of the followingtypes:

1) Activity—when a Service is free of charge, such as an Activity youonly share with friends, you can specify the Activity type when creatinga PricingModel for the Service.

Attributes:

name (optional)—an optional name for the PricingModel

notes (optional)—an optional notes field for the PricingModel

2) FixedPrice—if the price of a Service is constant, no matter theduration a customer can reserve for, specify the FixedPrice type whencreating a PricingModel for the Service. An example of such a Servicewould be a “Man with a Van” that charges for the entire day of work nomatter whether the customer requested 2 hours or 8 hours of time on anygiven day.

Attributes

price (required)—price that will be charged for the entire Service

currency (optional)—currency of price. Defaults to USD

name (optional)—an optional name for the PricingModel

notes (optional)—an optional notes field for the PricingModel

3) ByTheHour—when Services are charged for each hour being reserved,specify the ByTheHour type when creating a PricingModel for the Service.There are many examples of businesses that offer Services or classes bythe hour, such as salons, yoga studios, guitar lessons, etc.

Attributes

price (required)—price that will be charged for each hour reserved

currency (optional)—currency of price. Defaults to USD

name (optional)—an optional name for the PricingModel

notes (optional)—an optional notes field for the PricingModel

4) ByTheMinute—when Services are charged for each minute being reserved,specify the ByTheMinute type when creating a PricingModel for theService. Examples of Services that may charge by the minute may includetutoring, a help line, etc.

Attributes

price (required)—price that will be charged for each minute reserved

currency (optional)—currency of price; defaults to USD

description (optional)—an optional description for the PricingModel

Resources

Resources are what actually provide Services/Activities. By default, aBasic User is a Resource for their own Services/Activities (recall thata Basic User can only offer free Activities while a Pro User can chargea fee for their Services). Pro Users are able to create additionalResources for Services, besides just offering Services themselves. Thefollowing types of Resources may be created:

1) Person—a User can create another Person Resource, such as anotherinstructor at a gym, or a therapist at a spa.

Attributes

first_name—person's first name

last_name—person's last name

2) Place—a Place Resource would apply to something like a classroom,which hosts a particular Service at a time, or maybe a meeting roomonline where tutoring is offered.

Attributes

name—the name of this Place

capacity—an optional limit to how many Bookings are allowed at a singletime for this Place

3) Thing—a Thing Resource would apply to something like a van orequipment which is offered for rent for a certain amount of time.

Attributes

name—the name of this Thing

4) Schedules

Schedules: they start on a date, may end on a date, or possibly repeatindefinitely; falling between certain hours on particular days of theweek. By defining a Schedule for a Service that is offered by aResource, it is possible to advertise the available times the Servicemay be booked. In some embodiments, a Schedule is made up of a single ormany TimeWindows, where the most important attributes of a TimeWindoware the following:

start_date—what date it begins on;

end_date—what date it ends on (if any); no end_date means this scheduledwindow of time is valid forever;

days—the days of the week it falls on, such as Sunday through Saturday,everyday, weekends, etc.;

start_time—the earliest appointment time for the service;

end_time—when the last appointment must be finished by.

Types of Recurring TimeWindows

In some cases, a period of advanced time will continue be offered in arecurring fashion, such as:

daily—specify this kind of recurrence if a Service is offered everysingle day at the same time (this makes specifying days unnecessary).

weekly—something that recurs every week, such as a class

monthly—something that recurs every month (it is possible to specifythat something recurs only the first week of each month as well)

yearly—this is useful for Services that happen on some date or stretchof days every year

Frequency

Frequency is a kind of multiplier for how the TimeWindow recurs. Forexample, a monthly TimeWindow with days=‘weekend’ and frequency=‘everyother’ and interval=‘every’ implies that we are interested in aTimeWindow that actually recurs “every weekend every other month”.

Occurrence

Interval tells us exactly which instance of a TimeWindow's recurrence weare interested in. For example, a monthly TimeWindow with days=‘weekend’and frequency=‘every_other’ and interval=‘2nd_to_last’ implies that weare interested in a TimeWindow that actually recurs “every 2nd to lastweekend every other month”.

5) Categories

Categories are a way of organizing or tagging availableServices/Activities.

6) Search Results

A specifically programmed Search graphical user interface for retrievingServices/Activities that meet search criteria such as Category name,geographic distance, rating, price, etc.

7) Bookings

In some embodiments, a Booking represents the commitment by one user toattend a Service/Activity of another user at a particular time. The APIallows the creation and management of Bookings.

GET/bookings

This will look up all uncompleted Bookings that your account has accessto—this includes all Bookings under your own User account as well as anyBookings of Users for which you are the Account Manager.

Optional Parameters:

user_id—provide a User ID to see only this User's Bookings

states—provide a comma-separated list of Booking states in order to onlyretrieve Bookings in those states. Leave blank to retrieve all possiblestates.

page—result page of interest, default: 1

per_page—number of results per page, default: 10.

GET/bookings/{id}

Look up details for a Booking by ID. You can access details for anyService under your own User account as well as any Bookings of Users forwhich you are the Account Manager.

Required Parameters:

id—id of booking to retrieve.

POST/bookings/new

Create a new Booking. Your own User account will by default be recordedas the initiator of the booking. Optionally, provide a user_id for aUser you are the Account Manager of in order to create a booking.

Required Parameters:

service_id—the ID of the Service that is to be booked

date—provide the date of the requested Booking. Several formats aresupported: “October 31, 2014”, “10/31/2014”, “2014-10-31”

time—provide the time of the requested Booking. Several formats aresupported: “9 am”, “09:00”, “9:00”, “0900”

Optional Parameters:

resource_id—the ID of a Resource to be booked. If not provided, thefirst available Resource will be booked.

duration—if the service allows requesting a variable amount of time,specify how many minutes are desired

user_id—ID of a User you are the Account Manager of for whom you wouldlike to initiate a booking.

PUT/bookings/{id}

Update information for a Booking. The ID must be of a Booking that isunder your User account or any User for which you are the AccountManager. You can not update appointment time information for a Bookingonce placed. This action is a placeholder for future update-ableinformation.

DELETE/bookings/{id}

Attempt to cancel a Booking by ID. The ID must be of a Booking that isunder your User account or any User for which you are the AccountManager. If cancellation is not possible, this will return an errormessage.

Required Parameters:

id—id of booking to cancel

Categories

GET/categories

This will look up all Categories in the system. If retrieving Categoriesfor a particular User, you must be authorized to manage this User.

Optional Parameters:

user_id—provide a User ID to see only the Categories of Services offeredby a particular User

page—result page of interest, default: 1

per_page—number of results per page, default: 10

GET/categories/{id}

Look up details for a Category by ID. You can access details for anyCategory.

Required Parameters:

id—id of category to retrieve

POST/categories/new

Create a new Category. Please note that once created, it can not bemodified. A duplicate named Category under the same Parent Category IDis not permitted.

Required Parameters:

name—name of new Category

description—description for Category

Optional Parameters:

short_name—abbreviated name for Category

long_name—full name of Category

parent_category_id—id of parent Category

PricingModels

GET/pricing models

This will look up all PricingModels in the system.

Optional Parameters:

user_id—provide a User ID to see only this User's PricingModels

page—result page of interest, default: 1

per_page—number of results per page, default: 10

GET/pricing models/{id}

Look up details for a PricingModel by ID. You can access details for anyPricingModel under your own User account as well as any PricingModels ofUsers for which you are the Account Manager.

POST/pricing_models/new

Create a new PricingModel. Your own User account will automaticallybecome the Account Manager for any newly created PricingModels.

Required Parameters:

name—name of Pricing Model being created

type—type of Pricing Model (must be a valid type, see Entities above)

Optional Parameters:

user_id—provide a User ID of a managed User to create a Pricing Modelfor this User

price—price, if applicable

currency—3-letter ISO currency code

notes—additional notes about Pricing Model

PUT/pricing models/{id}

Update information for a PricingModel. The ID must be of a PricingModelthat is under your User account or any User for which you are theAccount Manager.

Optional Parameters:

name—new name of Pricing Model

Resources

GET/resources

This will look up all Resources that your account has access to—bydefault this includes all Resources under your own User account as wellas any Resources of Users for which you are the Account Manager. Provideuser_id of a managed User to return only the Resources for that User.

Optional Parameters:

user_id—provide a User ID to see only this User's Resources

page—result page of interest, default: 1

per_page—number of results per page, default: 10

GET/resources/{id}

Look up details for a Resource by ID. You can access details for anyResource under your own User account as well as any Resources of Usersfor which you are the Account Manager.

POST/resources/new

Create a new Resource. By default your own User account willautomatically become the Account Manager for any newly createdResources.

Required Parameters:

name—name of Pricing Model being created

type—type of Pricing Model. must be a valid type, see Entities above.

Optional Parameters:

user_id—provide a User ID of a managed User to create a resource forthis user

gender—gender of Resource, if applicable

capacity—capacity of Resource, if applicable

description—description of Resource

PUT/resources/{id}

Update information for a Resource. The ID must be of a Resource that isunder your User account or any User for which you are the AccountManager. You can not update Resources that were previously deleted.

Optional Parameters:

name—new name of Resource

DELETE/resources/{id}

Delete a Resource by ID. The ID must be of a Resource that is under yourUser account or any User for which you are the Account Manager. Deletionis a multi-step process: first the Resource is marked inactive and nolonger appears in Search results; if no Bookings exist for this Resourcethen it is completely destroyed, otherwise it is kept archived forhistorical purposes. You cannot delete Resources that were previouslydeleted.

Schedules

GET/schedules

This will look up all Schedules that your account has access to—thisincludes all Schedules under your own User account as well as anySchedules of Users for which you are the Account Manager.

Optional Parameters:

user_id—provide a User ID to see only this User's Schedules for theirServices

page—result page of interest, default: 1

per_page—number of results per page, default: 10

GET/schedules/{id}

Look up details for a Schedule by ID. You can access details for anySchedule under your own User account as well as any Schedules of Usersfor which you are the Account Manager.

POST/schedules/new

Create a new Schedule. A Schedule is created in the context of a Servicethat is provided by a Resource. Recall that a Basic User isautomatically a Resource for their own Services. A Pro User has theability to create additional Resources, in addition to their own, eachone of which can provide their own set of Services with their ownSchedules.

In some embodiments, to save an API call, one can pass parameters forthe first TimeWindow as part of the Schedule creation (see POST paramsfor TimeWindow). Although these parameters are described below inrelation to the Schedule being created, they are used to create thefirst TimeWindow that will make up this Schedule.

While marked optional for Schedule creation, there is still validationperformed to ensure that all necessary parameters for TimeWindowcreation have been properly supplied if any are provided.

Required Parameters:

service_id—provide the Service ID that is being scheduled

Optional Parameters:

user_id—provide a User ID to create a Schedule for this User. You mustbe authorized to manage this User and User must own desired Service andResource.

resource_id—provide the Resource ID that is being scheduled. If notprovided and user_id is not present, the default Resource of the APIuser is assumed to be the Resource being scheduled. If not provided anduser_id is present, the default Resource of the User is assumed to bethe Resource being Scheduled.

start_date—start date of the TimeWindow. Several formats are supported:“October 31, 2014”, “10/31/2014”, “2014-10-31”

end_date—end date of the TimeWindow. Several formats are supported:“October 31, 2014”, “10/31/2014”, “2014-10-31”. If no end_date isspecified this TimeWindow is deemed “infinite”.

start_time—start time of the TimeWindow. Several formats are supported:“9 am”, “09:00”, “9:00”, “0900”

end_time—end time of the TimeWindow. Several formats are supported: “5pm”, “17:00”, “1700”

total_minutes—only necessary if the length of the Service cannot bededuced from end_time minus start_time. An example would be a Servicethat actually lasts 36 hours from 10 am to 10 pm the next day. This mustbe specified in number of minutes, eg. 2160=36 hours.

days—a String list of comma-separated days of the week this window oftime falls on: “sunday, monday, tuesday, wednesday, thursday, friday,saturday”. At least one must be specified. The order supplied does notmatter.

recurs_by—one and only one of the following possible values: [once,daily, weekly, monthly, yearly].

frequency—one of the following possible values: [single, every,every_other, every_3rd, every_4th, . . . , every_(Nth)] where Nth max is‘100th’. If nothing is specified, the default value is ‘every’.

occurrence—one of the following possible values: [every, 1st, 2nd, 3rd,. . . , (Nth), last, 2nd_to_last, 3rd_to_last, . . . , (Mth)_to_last]where Nth max is ‘366th’ and Mth max is ‘10th’. If nothing is specified,the default value is ‘every’.

date_recurs_by—this field is optional except when ‘recurs_by’ is one of‘monthly’ or ‘yearly’. For those two types of TimeWindows this fieldmust be one of [date_in_month, day_in_month] for ‘monthly’ and[date_in_year, day_in_year] for ‘yearly’, respectively. ‘day_in_month’specifies that we're interested in the day that is represented by thedate in the month, for example, the “2nd Tuesday” of the month.‘day_in_year’ specifies that we're interested in the day that isrepresented by the date in the year, for example, the “182nd” day of theyear.

POST/schedules/{id}/time_windows/new

Create a TimeWindow for Schedule specified by Schedule ID. The ScheduleID must be of a Schedule that is under your User account or any User forwhich you are the Account Manager.

Required Parameters:

id—id of Schedule being modified

start_date—start date of the TimeWindow. Various formats can besupported: “October 31, 2014”, “10/31/2014”, “2014-10-31”

start_time—start time of the TimeWindow. Various formats can besupported: “9 am”, “09:00”, “9:00”, “0900”

end_time—end time of the TimeWindow. Various formats can be supported:“5 pm”, “17:00”, “17:00”, “1700”

days—a String list of comma-separated days of the week this window oftime falls on: “sunday, monday, tuesday, wednesday, thursday, friday,saturday”. At least one must be specified. In some embodiments, theorder supplied does not matter.

recurs_by—one and only one of the following possible values: [once,daily, weekly, monthly, yearly].

Optional Parameters:

end_date—end date of the TimeWindow. Several formats are supported:“October 31, 2014”, “10/31/2014”, “2014-10-31”. If no end_date isspecified this TimeWindow is deemed “infinite”.

total_minutes—only necessary if the length of the Service cannot bededuced from end_time minus start_time. An example would be a Servicethat actually lasts 36 hours from 10 am to 10 pm the next day. This mustbe specified in number of minutes, eg. 2160=36 hours.

frequency—one of the following possible values: [single, every, everyother, every_3rd, every_4th, . . . , every_(Nth)] where Nth max is‘100th’. If nothing is specified, the default value is ‘every’.

occurrence—one of the following possible values: [every, 1st, 2nd, 3rd,. . . , (Nth), last, 2nd_to_last, 3rd_to_last, . . . , (Mth)_to_last]where Nth max is ‘366th’ and Mth max is ‘10th’. If nothing is specified,the default value is ‘every’.

date_recurs_by—this field is optional except when ‘recurs_by’ is one of‘monthly’ or ‘yearly’. For those two types of TimeWindows this fieldmust be one of

date_in_month, day_in_month] for ‘monthly’ and [date_in_year,day_in_year] for ‘yearly’, respectively. ‘date_in_XX’ specifies that theactual date is required. ‘day_in_month’ specifies that we're interestedin the day that is represented by the date in the month, for example,the “2nd Tuesday” of the month. ‘day_in_year’ specifies that we'reinterested in the day that is represented by the date in the year, forexample, the “182nd” day of the year.

PUT/schedules/{id}/time_windows/{time_window_id}

Update information for a TimeWindow of a Schedule. The Schedule ID mustbe of a Schedule that is under your User account or any User for whichyou are the Account Manager.

Required Parameters:

id—id of Schedule being modified

time_window_id—id of TimeWindow being modified

Optional Parameters:

start_date—start date of the TimeWindow. Several formats are supported:“October 31, 2014”, “10/31/2014”, “10-31-2014”

end_date—end date of the TimeWindow. Several formats are supported:“October 31, 2014”, “10/31/2014”, “10-31-2014”. If no end_date isspecified this TimeWindow is deemed “infinite”.

start_time—start time of the TimeWindow. Several formats are supported:“9 am”, “09:00”, “9:00”, “0900”

end_time—end time of the TimeWindow. Several formats are supported: “5pm”, “17:00”, “17:00”, “1700”

days—a String list of comma-separated days of the week this window oftime falls on: “sunday, monday, tuesday, wednesday, thursday, friday,saturday”. At least one must be specified. The order supplied does notmatter.

recurs_by—one and only one of the following possible values: [once,daily, weekly, monthly, yearly].

total_minutes—only necessary if the length of the Service can not bededuced from end_time minus start_time. An example would be a Servicethat actually lasts 36 hours from 10 am to 10 pm the next day. This mustbe specified in number of minutes, eg. 2160=36 hours.

frequency—one of the following possible values: [single, every, everyother, every_3rd, every_4th, . . . , every_(Nth)] where Nth max is‘100th’. If nothing is specified, the default value is ‘every’.

occurrence—one of the following possible values: [every, 1st, 2nd, 3rd,. . . , (Nth), last, 2nd_to_last, 3rd_to_last, . . . , (Mth)_to_last]where Nth max is ‘366th’ and Mth max is ‘10th’. If nothing is specified,the default value is ‘every’.

date_recurs_by—this field is optional except when ‘recurs_by’ is one of‘monthly’ or ‘yearly’. For those two types of TimeWindows this fieldmust be one of [date_in_month, day_in_month] for ‘monthly’ and[date_in_year, day_in_year] for ‘yearly’, respectively. ‘date_in_XX’specifies that the actual date is required. ‘day_in_month’ specifiesthat we're interested in the day that is represented by the date in themonth, for example, the “2nd Tuesday” of the month. ‘day_in_year’specifies that we're interested in the day that is represented by thedate in the year, for example, the “182nd” day of the year.

DELETE/schedules/{id}/time_windows/{time_window_id}

Delete a TimeWindow of a Schedule. The Schedule ID must be of a Schedulethat is under your User account or any User for which you are theAccount Manager.

Required Parameters:

id—id of Schedule being modified

time_window_id—id of TimeWindow being modified

DELETE/schedules/{id}

Delete a Schedule by ID. The ID must be of a Schedule that is under yourUser account or any User for which you are the Account Manager. Deletionis a multi-step process: first the Schedule is marked inactive and nolonger appears in Search results; if no Bookings exist for this Schedulethen it is completely destroyed, otherwise it is kept archived forhistorical purposes. You cannot delete Schedules that were previouslydeleted.

Required Parameters:

id—id of Schedule being modified

Search

GET/search/{query}

All Service/Activities that match given search criteria will bereturned.

Required Parameters:

query—search query

Optional Parameters:

page—result page of interest, default: 1

per_page—number of results per page, default: 10

Services

GET/services

This will look up all Services that your account has access to—thisincludes all Services under your own User account as well as anyServices of Users for which you are the Account Manager.

Optional Parameters:

user_id—provide a User ID to see only this User's Services

page—result page of interest, default: 1

per_page—number of results per page, default: 10

GET/services/{id}

Look up details for a Service by ID. You can access details for anyService under your own User account as well as any Services of Users forwhich you are the Account Manager.

GET/services/{id}/available_slots

Look up available time slots for a Service by ID. You can query for aspecific date or for a date range. The returned result set will groupavailable slots by Resources that are offering the Service. You canaccess details for any Service under your own User account as well asany Services of Users for which you are the Account Manager.

Required Parameters:

id—ID of desired Service

Optional Parameters:

date—a specific date to check for availability. Either this field or adate range employing start_date and end_date must be supplied. If dateis provided, start_date/end_date are ignored. Several formats aresupported: “2014-10-31”, “October 31, 2014”.

start_date—start date of a date range to check for availability. Ifsupplied, date must not be supplied and end_date must be supplied.Several formats are supported: “2014-10-31”, “October 31, 2014”.

end_date—end date of a date range to check for availability. Ifsupplied, date must not be supplied and start_date must be supplied.Several formats are supported: “2014-10-31”, “October 31, 2014”.

POST/services/new

Create a new Service. Unless a user_id is provided, your own Useraccount will automatically become the Account Manager for any newlycreated services.

Required Parameters:

name—name of the Service

description—a description for the Service

duration—minimum number of minutes required to perform this Service

Optional Parameters:

user_id—provide a User ID to create a Service for this User. You must beauthorized to manage this User.

short_name—an abbreviated name for the Service, used where space islimited

price_model_id—ID of a PricingModel for this service, that your accounthas permission to use

resources—a string of Resource IDs, comma-separated; if user_id isprovided, all Resources must be owned by the User, defaults to User'sResource ID; if user_id is not provided, all Resources must be owned byAPI User; defaults to API User's Resource ID

categories—a string of Category IDs, comma-separated

PUT/services/{id}

Update information for a Service. The ID must be of a Service that isunder your User account or any User for which you are the AccountManager. You can not update Services that were previously deleted.

Required Parameters:

id—ID of desired Service to modify

Optional Parameters:

name—name of the Service

description—a description for the Service

duration—minimum number of minutes required to perform this Service

short_name—an abbreviated name for the Service, used where space islimited

price_model_id—ID of a PricingModel for this Service

resources—a string of Resource IDs, comma-separated; all resources mustbe owned by the same user; defaults to API User's Resource ID

categories—a string of Category IDs, comma-separated

DELETE/services/{id}

Delete a Service by ID. The ID must be of a Service that is under yourUser account or any User for which you are the Account Manager. Deletionis a multi-step process: first the Service is marked inactive and nolonger appears in Search results; if no Bookings exist for this Servicethen it is completely destroyed, otherwise it is kept archived forhistorical purposes. You cannot delete Services that were previouslydeleted.

Users

GET/users

This will look up all Users that your account has access to—thisincludes your own User account as well as any Users for which you arethe Account Manager.

Optional Parameters:

page—result page of interest, default: 1

per_page—number of results per page, default: 10

GET/users/{id}

Look up details for a User by ID. You can access details for your ownUser account as well as any Users for which you are the Account Manager.

POST/users/new

Create a new User. Your own User account will automatically become theAccount Manager for any newly created Users.

PUT/users/{id}

Update information for a User. The ID can be your own User account orthe ID of any User of which you are the Account Manager. If thespecified User has a password on file, changing the User's email addresswill invalidate the password and send a Reset Password email to theUser.

PUT/users/{id}/register_pro

Upgrade a User by ID from a Basic to a Pro user.

GET/users/{id}/request_password

This will send a Reset Password email to the specified User's emailaddress containing a link where they can reset their password. This willreturn all Users that are currently Pro Users, for which you are theAccount Manager, including your own account.

GET/users/pros

This will return all Users that are currently Pro Users, for which youare the Account Manager, including your own account.

In some embodiments, the present invention provides for acomputer-implemented method, including at least the steps of:electronically causing, via a computer network, by at least onespecifically programmed computer processor of a schedule managementcomputer system executing software to perform the method, to display afirst specialized schedule graphical user interface (a first specializedschedule GUI) on a screen of each computing device associated with eachuser of a plurality of users; where the first specialized schedule GUIis configured to allow each user to: i) define at least one programmedschedule object, including a plurality of availability time periods (aplurality of TimeWindows), and ii) associate at least one programmedschedule object with at least one of: 1) at least one user, 2) at leastone resource, and 3) at least one service; where each TimeWindow is: i)defined by a plurality of TimeWindow parameters, and ii) configured toidentify whether a corresponding time period is available for booking orunavailable for booking; where the plurality of TimeWindow parametersinclude: i) at least one first TimeWindow parameter, identifying a startdate for the corresponding time period, ii) at least one secondTimeWindow parameter, identifying a start time for the correspondingtime period, iii) at least one third TimeWindow parameter, identifyingan end time for the corresponding time period, iv) at least one fourthTimeWindow parameter, identifying at least one day of a week associatedwith the corresponding time period, and v) at least one fifth TimeWindowparameter, identifying a period type of the corresponding time period;electronically and in real-time, generating, by the at least onespecifically programmed computer processor, based, at least in part, onthe at least one fourth TimeWindow parameter, a first bitmask of days ina week for the corresponding time period of each TimeWindow of theplurality of TimeWindows; electronically and in real-time, storing, bythe at least one specifically programmed computer processor, a pluralityof schedule objects associated with the plurality of users in at leastone specifically dedicated database;

electronically causing, via the computer network, by the at least onespecifically programmed computer processor, to display a secondspecialized schedule graphical user interface (a second specializedschedule GUI) on a screen of a computing device associated with aparticular user, where the second specialized schedule GUI is configuredto allow each user to submit an electronic query seeking to determinewhen a particular time period associated with at least one user isavailable for booking or unavailable for booking; electronicallyreceiving, via the computer network, by the at least one specificallyprogrammed computer processor, the electronic query of the particularuser; electronically and in real-time, determining, by the at least onespecifically programmed computer processor, based on the electronicquery of the particular user, a set of TimeWindows selected from theplurality of schedule objects related to at least one of 1) the at leastone user, 2) the at least one resource, and 3) the at least one service;electronically and in real-time, determining, by the at least onespecifically programmed computer processor, based on the electronicquery of the particular user, a set of TimeWindows selected from theplurality of schedule objects related to at least one of 1) the at leastone user, 2) the at least one resource, and 3) the at least one service;electronically and in real-time, generating, by the at least onespecifically programmed computer processor, a union structure of the setof TimeWindows; electronically and in real-time, determining, by the atleast one specifically programmed computer processor, based on the firstbitmask associated with each TimeWindow of the set of TimeWindows, asecond bitmask corresponding to the at least one union; electronicallyand in real-time, determining, by the at least one specificallyprogrammed computer processor, an intersection structure between theunion and the electronic query of the particular user to identify atleast one matched day of the week between the at least one union and theparticular time period identified in the electronic query of theparticular user; electronically and in real-time, determining, by the atleast one specifically programmed computer processor, when the at leastone matched day of the week includes the particular time periodidentified in the electronic query of the particular user, based, atleast in part, on: 1) the at least one second TimeWindow parameter of aparticular TimeWindow associated with the at least one matched day ofthe week; 2) the at least one third TimeWindow parameter of theparticular TimeWindow associated with the at least one matched day ofthe week; 3) the at least one second TimeWindow parameter of theparticular time period identified in the electronic query of theparticular user; and 4) the at least one third TimeWindow parameter ofthe particular time period identified in the electronic query of theparticular user; and electronically and in real-time, performing, by theat least one specifically programmed computer processor, one of: i)booking the particular time period for the particular user when the atleast one matched day of the week includes the particular time periodidentified in the electronic query of the particular user; and ii)generating an indication identifying that the particular time period isunavailable for booking when the at least one matched day of the weekexcludes the particular time period identified in the electronic queryof the particular user. In some embodiments, the exemplary method of thepresent invention further includes at least: electronically and inreal-time, storing, by the at least one specifically programmed computerprocessor, the union structure and the intersection structure in the atleast one specifically dedicated database.

In some embodiments, the plurality of parameters further include atleast one sixth parameter, identifying an end date for the correspondingtime period. In some embodiments, the period type of the correspondingtime period is selected from the group consisting of: once, daily,weekly, monthly, quarterly, and yearly. In some embodiments, theplurality of parameters further include at least one seventh parameter,identifying a particular date or a particular day which is within thecorresponding time period having the period type of monthly or yearly.In some embodiments, the plurality of parameters further include atleast one eighth parameter, identifying a frequency of the correspondingtime period. In some embodiments, the plurality of parameters furtherinclude at least one ninth parameter, identifying an interval for thefrequency of the corresponding time period. In some embodiments, theunion structure is based on a logical OR operation with the set ofTimeWindows. In some embodiments, the intersection structure is based ona logical AND operation.

In some embodiments, the present invention provides for a specificallyprogrammed schedule management computer system, including at least: atleast one specialized computer machine, including: a non-transientmemory, electronically storing particular computer executable programcode; and at least one computer processor which, when executing theparticular program code, becomes a specifically programmed computerprocessor of the specifically programmed schedule management computersystem that is configured to concurrently perform at least the followingoperations: electronically causing, via a computer network, to display afirst specialized schedule graphical user interface (a first specializedschedule GUI) on a screen of each computing device associated with eachuser of a plurality of users; where the first specialized schedule GUIis configured to allow each user to: i) define at least one programmedschedule object, including a plurality of availability time periods (aplurality of TimeWindows), and ii) associate at least one programmedschedule object with at least one of: 1) at least one user, 2) at leastone resource, and 3) at least one service; where each TimeWindow is: i)defined by a plurality of TimeWindow parameters, and ii) configured toidentify whether a corresponding time period is available for booking orunavailable for booking; where the plurality of TimeWindow parametersinclude: i) at least one first TimeWindow parameter, identifying a startdate for the corresponding time period, ii) at least one secondTimeWindow parameter, identifying a start time for the correspondingtime period, iii) at least one third TimeWindow parameter, identifyingan end time for the corresponding time period, iv) at least one fourthTimeWindow parameter, identifying at least one day of a week associatedwith the corresponding time period, and v) at least one fifth TimeWindowparameter, identifying a period type of the corresponding time period;electronically and in real-time, generating, based, at least in part, onthe at least one fourth TimeWindow parameter, a first bitmask of days ina week for the corresponding time period of each TimeWindow of theplurality of TimeWindows; electronically and in real-time, storing aplurality of schedule objects associated with the plurality of users inat least one specifically dedicated database; electronically causing,via the computer network, to display a second specialized schedulegraphical user interface (a second specialized schedule GUI) on a screenof a computing device associated with a particular user, where thesecond specialized schedule GUI is configured to allow each user tosubmit an electronic query seeking to determine when a particular timeperiod associated with at least one user is available for booking orunavailable for booking; electronically receiving, via the computernetwork, the electronic query of the particular user; electronically andin real-time, determining, based on the electronic query of theparticular user, a set of TimeWindows selected from the plurality ofschedule objects related to at least one of 1) the at least one user, 2)the at least one resource, and 3) the at least one service;electronically and in real-time, determining, based on the electronicquery of the particular user, a set of TimeWindows selected from theplurality of schedule objects related to at least one of 1) the at leastone user, 2) the at least one resource, and 3) the at least one service;electronically and in real-time, generating a union structure of the setof TimeWindows; electronically and in real-time, determining, based onthe first bitmask associated with each TimeWindow of the set ofTimeWindows, a second bitmask corresponding to the at least one union;electronically and in real-time, determining an intersection structurebetween the union and the electronic query of the particular user toidentify at least one matched day of the week between the at least oneunion and the particular time period identified in the electronic queryof the particular user; electronically and in real-time, determiningwhen the at least one matched day of the week includes the particulartime period identified in the electronic query of the particular user,based, at least in part, on: 1) the at least one second TimeWindowparameter of a particular TimeWindow associated with the at least onematched day of the week; 2) the at least one third TimeWindow parameterof the particular TimeWindow associated with the at least one matchedday of the week; 3) the at least one second TimeWindow parameter of theparticular time period identified in the electronic query of theparticular user; and 4) the at least one third TimeWindow parameter ofthe particular time period identified in the electronic query of theparticular user; and electronically and in real-time, performing one of:i) booking the particular time period for the particular user when theat least one matched day of the week includes the particular time periodidentified in the electronic query of the particular user; and ii)generating an indication identifying that the particular time period isunavailable for booking when the at least one matched day of the weekexcludes the particular time period identified in the electronic queryof the particular user.

As generally illustrated herein, the system embodiments can incorporatea variety of computer readable media that comprise computer usablemedium having computer readable code means embodied therein. One skilledin the art will recognize that the software associated with the variousprocesses described can be embodied in a wide variety of computeraccessible media from which the software is loaded and activated.Pursuant to In re Beauregard, 35 USPQ2d 1383 (U.S. Pat. No. 5,710,578),the present invention anticipates and includes this type of computerreadable media within the scope of the invention. Pursuant to In reNuijten, 500 F.3d 1346 (Fed. Cir. 2007) (U.S. patent application Ser.No. 09/211,928), the present invention scope is limited to computerreadable media wherein the media is both tangible and non-transitory.

The method and system of the present invention have been described aboveand in the attached drawings; however, modifications will be apparent tothose of ordinary skill in the art and the scope of protection for theinvention is to be defined by the claims that follow.

What is claimed is:
 1. A computer-implemented method, comprising:electronically causing, via a computer network, by at least onespecifically programmed computer processor of a schedule managementcomputer system executing software to perform the method, to display afirst specialized schedule graphical user interface (a first specializedschedule GUI) on a screen of each remotely distributed computing deviceassociated with each user of a plurality of users; wherein the pluralityof users are associated with a plurality of remotely distributedcomputing devices; executing, in real-time, by the at least onespecifically programmed computer processor, a programmed softwarescheduling module which at least perform the following operations:electronically and in real-time, storing a plurality of programmedsoftware schedule objects associated with the plurality of users in atleast one specifically dedicated database, wherein each programmedsoftware schedule object comprises the plurality of bitmask dataobjects; electronically receiving, via the computer network, theelectronic query of the particular user; electronically and inreal-time, determining, based on the electronic query of the particularuser, a set of programmed software schedule objects related to at leastone of 1) the at least one user, 2) the at least one resource, and 3)the at least one service; and generating an electronic scheduling alerton a screen of remotely distributed computing device associated with aparticular user, wherein the electronic scheduling alert identifies aparticular available time period based on the set of programmed softwareschedule objects.